Applications can encrypt data locally on a user device, such as a cell phone, laptop, or tablet. Different applications can use different keys that can be unlocked independently with the correct user passcode, or pin. This is particularly useful in the context of an enterprise mobility management (“EMM”) system. When enrolled in an EMM system, users can install applications on their own user devices that access and store enterprise data. The locally stored enterprise data can be encrypted with a key that is derived separately from the device login. This provides an extra layer of data encryption that the enterprise can ultimately control. For example, the enterprise can control when the user is able to decrypt the data and can even wipe the data from the user device, such as if the user leaves the enterprise.
Some enterprises require applications to use passcode-based encryption (“PBE”) for application-specific encryption. PBE can prompt the user for a passcode (separate from device login) that is used to generate a key for encrypting and decrypting application-specific data. For example, using a key generated with PBE, the application can access a local encrypted database that securely stores the application's data.
However, PBE poses difficulties on some operating systems (“OS”). For example, ANDOID does not allow for persistent storage of the passcode or key in a secure manner. Instead, the ANDROID OS can periodically wipe the user passcode from temporary memory, such as cache, as part of normal maintenance. This causes problems for applications that rely on the passcode to access encrypted data because the passcode is deleted the application can no longer access its data. The ANDROID OS is not designed to accommodate an application that cannot access its own data.
As an example, an email application that stores its data in a local encrypted database needs the user passcode to generate a key to access the encrypted database. Without accessing the data, the application cannot properly operate. When the OS wipes the passcode from cache, it is no longer available. Although the email application can prompt the user to reenter the user passcode, doing so every time the application needs to read or write data negatively affects the user experience. Repeated prompts also do not solve all of the issues. For example, background services utilized by an email application might require data access and can be incapable of prompting the user for the passcode.
Further, the OS can initiate OS events at the email application regardless of whether the user passcode is available. For example, a user interface (“UI”) action, such as the email application entering the display foreground, can cause the OS to call a lifecycle method at the email application. This is done even though the email application cannot access its data (because the user passcode is unavailable). Similarly, OS services can be used to perform background services for the email application without regard to the availability of the user passcode. The ANDROID Sync Manager can similarly schedule various operations without accounting for whether the user passcode exists. Since the application cannot access its data without the user passcode, the application will fail to correctly respond to the OS events.
As one example, the email application can depend on triggers from the OS to launch various services so that the email application will retrieve new messages and otherwise update itself. Without access to the user passcode, the update cannot occur. The email application might consider itself updated when it actually is not. It might not alert the user to new messages and can even crash. Because ANDROID does not provide a way to dynamically register and unregister these triggers, the email application can operate erratically. Confusing things even further, the ANDROID OS may attempt to restart services that fail, and those services will continue to fail without the user passcode. This can lead to unpredictable results.
The application can also miss crucial system changes when it cannot access its data. This could include a time or locale change or, in the EMM context, something as crucial as a data wipe command.
To summarize, without guaranteed access to the user passcode, multiple challenges exist for proper email application operation with PBE. Since the passcode is used to protect email application data, losing the passcode means the email application cannot access its own data. As a result, the email application can no longer sync any new data from the server or update any data already stored locally. Additionally, multiple processes and background services are set up to run periodically—regardless of whether the data is locked. In some cases, the email application also depends on triggers from the OS to launch the services updating the email application. When these services run without the user passcode, the email application can crash. The ANDROID OS, by default, tries to help applications recover. Therefore, even if a process is stopped because the passcode is unavailable, the OS can restart it.
To ensure successful operation throughout this scenario, a need exists for a management framework for an email application using PBE.